The present invention generally relates to wireless communications, and in particular, to an optimized radio bearer configuration for voice over Internet protocol (VoIP).
The present invention relates to effectively providing VoIP (Voice over Internet Protocol) in a wireless environment, which is an IP (Internet Protocol) based voice service in a UMTS (Universal Mobile Telecommunications System), which is a European type IMT-2000 system. In particular, the present invention relates to configuring a radio bearer that is optimized for VoIP, by transmitting RTP (Real-time Transport Protocol) packets and RTCP (RTP Control Protocol) packets, which are used in providing VoIP services, via RLC (Radio Link Control) entities that have respectively different modes according to respective packet characteristics, such that the QoS (Quality of Service) for VoIP can be improved.
Voice over Internet Protocol (VoIP) refers to a service for transmitting voice data via an Internet Protocol (IP), to thus provide voice data in a PS (Packet Switched) domain instead of the conventional CS (Circuit Switched) domain. The advantage of VoIP, when compared to CS domain based voice services that transmit data while maintaining an end-to-end connection, is that network resources may be used very effectively because data transmissions occur in a connection-less state (i.e., without having to maintain an end-to-end connection). As communications technologies continue to develop, the amount of user data is also increasing rapidly. Thus, for effectively using network resources, the majority of conventional CS domain based services are now being replaced by PS domain based services. VoIP has been developed in this context, and it is expected that for practically all communications systems in the future, voice communications services will be provided through VoIP.
Although VoIP has the advantage of effectively using network resources, is the disadvantage is that its QoS (Quality of Service) is lower than that of conventional CS domain based voice services. There are many factors that affect the QoS, including delay, jitter (i.e., delay variation), FER (Frame Error Rate), etc. to name a few. When VoIP was first developed, its QoS was drastically lower than that for CS domain based voice services. However, due to much research and development, for wired (wireline) interface VoIP and for CS domain based voice services, the QoS of almost the same level can be guaranteed.
Through the research and development of wired interface VoIP, the RTP (Real-time Transport Protocol) that can effectively provide PS domain based voice services was developed. Also, the RTCP (RTP Control Protocol) that functions to provide feedback for RTP packet transmissions was developed. In RTP, time stamp information is contained within each packet, thus the problems related to jitter can be solved. In RTCP, the FER can be reduced by allowing the RTP source to perform rate control according to the reporting of any losses in RTP packets. In addition to the RTP and RTCP, the SIP (Session Initiation Protocol) and SDP (Session Description Protocol), etc. have also been developed for maintaining an end-to-end virtual connection.
As such, for wired interface VoIP, the QoS can be guaranteed to a level that is currently satisfactory, but for radio (wireless) interface VoIP, the QoS is significantly lower than that of CS domain based voice services. To increase the transmission efficiency for radio interface VoIP, an improved header compression technique, called ROHC (Robust Header Compression) has been developed and used. However, the overall QoS is still significantly lower than that of CS domain based voice services.
The greatest problem in supporting VoIP in the radio interface is that when RTP and RTCP packets (that are provided as a single stream in the wired interface) are also provided as a single stream in the radio interface, the QoS is decreased because their packet characteristics are respectively different. Namely, RTP packets, being real-time user data, are tolerant to errors but are sensitive to delays and jitter. RTCP packets, being control data, are tolerant to delays and jitter but are sensitive to errors. Also, because RTP packets contain voice data, packets having a relatively small size are transmitted frequently and regularly, and because RTCP packets contain control data, packets having a size that is quite large compared to RTP packets are transmitted infrequently and irregularly. If RTP packets and RTCP packets having respectively different characteristics are provided as a single stream in the radio interface, the QoS will decrease drastically in a wireless (radio) environment, which has much more inferior conditions than a wired environment.
Basically, a radio protocol handles the guaranteeing of the QoS in the radio interface for a particular service. The radio protocol differs according to the communications system, and the present disclosure will describe an asynchronous IMT-2000 system, namely, a UMTS (Universal Mobile Telecommunications System) based radio protocol. In UMTS, a RB (Radio Bearer) service is used for providing a particular service in the radio interface. The RB service is a service that the first and second layers (Layers 1 and 2) provide to the upper layers in a radio protocol. Currently, in UMTS, a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer are defined. The radio protocol layers directly affect the QoS of the radio interface, and because the radio interface has much more inferior conditions than the wired interface, it can be said that the radio protocol layers affect the overall end-to-end QoS. The radio protocols also play a major role in the transmission of RTP and RTCP packets, thus the transmission of RTP and RTCP packets in the radio interface will be considered in more detail.
FIG. 1 depicts a packet flow during VolP communications between two end-users in a UMTS. First, the voice data of End User 1 is sent to the RTP/RTCP via a codec protocol layer, and these voice data are included in the RTP packets. Then, the RTP packets pass through the UDP (User Datagram Protocol) and IP layers, and are transferred to the radio protocol in RTP/UDP/IP format. In the radio protocol, the PDCP layer first receives these packets and performs header compression thereon. Thereafter, the header compressed RTP/UDP/IP packets go through the RLC, MAC, and PHY layers, and then is transmitted through the radio interface. The wired network decompresses the compressed RTP/UDP/IP packets via the PHY/MAC/RLC/PDCP layers, which are peer entities to the radio protocol of End User 1.
In the wired interface, packets in RTP/UDP/IP format are transferred to the destination, and for transferring to the End User 2, the packets must go is through the radio protocol once again. The RTCP packets are generated by the end user receiving the RTP packets. In general, to provide feedback regarding the loss of RTP packets, transmissions are performed in a reverse direction from that of RTP packets, but in case of forward control (e.g., informing RTP source information, controlling the RTP receiver, etc.), transmissions can be performed in the same direction as that of RTP packets. Generally, as VoIP pertains to bidirectional communications between two end users, there are usually two RTP/RTCP flows that are transmitted in respectively different directions.
The RTP/RTCP packet transmissions in the radio (wireless) interface are handled by the PDCP/RLC/MAC/PHY layers, as described previously. It should be noted that these radio protocols provide not only RTP/RTCP packet transmissions, but also provide radio interface services for all services provided in UMTS. Radio protocols exist in pairs at each end of the radio interface, namely at a terminal and at a UTRAN (UMTS Terrestrial Radio Access Network), and operate in a peer-to-peer manner. In other words, the radio protocol layers in the terminal and those in the UTRAN have the same architecture (structure), and thus the architecture of only one of these portions (in the terminal or the UTRAN) will be considered for simplification.
FIG. 2 depicts the architecture (structure) of the radio protocol used in UMTS. Regarding each layer of the radio protocol, Layer 1 (PHY layer) provides information transfer service to an upper layer by using various radio transmission techniques, and is connected with the MAC layer thereabove via a transport channel, through which data is transmitted between the MAC and PHY layers. In Layer 2, the MAC, RLC, PDCP, and BMC layers exist. The MAC layer provides the re-allocation service of MAC parameters for allocation and re-allocation of radio resources, and is connected with the RLC layer (an upper layer) via a logical channel, whereby various logical channels are provided according to the type of data being transmitted. In general, a control channel is used when transmitting control plane data, while a traffic channel is used when transmitting user plane data.
The RLC layer handles the guaranteeing of QoS for each RB (radio bearer) and its data transmissions. As the RB service is a service that Layer 2 of the radio protocol provides to the upper layers, the entire Layer 2 affects the QoS, but the effect of the RLC is especially large. For guaranteeing the QoS that is unique to the RB, the RLC has one or two separate (independent) RLC entities for each RB, and three types of RLC modes (TM: transparent mode, UM: unacknowledged mode, and AM: acknowledged mode) for supporting various QoS. Each of these RLC modes operate differently because each supports different QoS, and their detailed functions are also respectively different. The RLC employs these independent RLC entities and various RLC modes in order to support the QoS that is appropriate for each RB.
The PDCP layer is located above the RLC layer and employs IP packets under IPv4 or IPv6 so that the transmitted data can be effectively transmitted in the radio interface that has a relatively smaller bandwidth. To achieve this, the PDCP layer performs the function of minimizing the amount of any unnecessary control information used in the wired network. This function is called header compression, which allows transmission of only required information in the data header such that transmission efficiency in the radio interface is increased. The PDCP layer, because header compression is a basic function, only exists in the PS domain, and one PDCP entity exists for each RB to provide effective header compression function for each PS service.
Also in Layer 2, a BMC (Broadcast/Multicast Control) layer exists above the RLC layer and handles the scheduling of cell broadcast messages to perform the function of broadcasting to terminals located within a particular cell, but is not involved with the transmission of RTP/RTCP packets.
The RRC (Radio Resource Control) layer, located at the lowermost portion of Layer 3, is only defined in the control plane and handles the control of transport channels and physical channels related to the establishing, re-establishing, and releasing of radio bearers (RBs). Here, as described previously, the RB refers to a service provided by Layer 2 for transferring data between the terminal and the UTRAN. In general, the establishing of the RB refers to the setting of the characteristics of the radio protocol layers and channels for providing a particular service, and also refers to the procedures in setting the individual particular parameters and operation methods.
As described above, there are three operation modes for the RLC layer, each of which operates differently. Each RLC mode should be considered in more detail to determine which RB mode is appropriate for which RB service.
First, the TM RLC mode is a mode in which no overhead is attached to the RLC SDU (Service Data Unit) received from an upper layer when constituting a RLC PDU (Protocol Data Unit). The TM RLC was basically developed for the purpose of processing voice data of the CS domain, whereby the RLC SDU size is fixed, thus the TM RLC uses the SDU itself to constitute the PDU, which is then transmitted. Namely, in TM RLC, the SDU and PDU are mapped in a one-to-one relationship and pass through in a transparent manner, hence the name “TM” (Transparent Mode) RLC.
Unlike the transparent mode, the mode in which an overhead is added at the RLC is called non-transparent mode, which has two types: unacknowledged mode (UM) that does not have transmission data reception confirmation reply, and acknowledged mode (AM) that has such reply.
The UM and AM RLCs were developed for the purpose of handling PS domain data, whereby the RLC SDU size may vary for each packet due to the characteristics of the PS domain data, and thus the SDUs undergo segmentation and concatenation to form PDUs having uniform size. To support the segmentation and concatenation of SDUs, an indicator (or identifier) indicating the boundary of the SDUs included in the PDU and a sequence number (SN) allowing discernment of each PDU is required, thus a PDU header is necessary.
The UM RLC transmits upon forming a PDU by attaching a header that includes information regarding the concatenation and segmentation of SDUs, and this mode is appropriate for real-time PS services, such as VoIP or PS streaming. Like UM RLC, the AM RLC form a PDU by attaching a PDU header, but unlike UM RLC, the receiving side (receiver) sends an acknowledgement for the PDU transmitted by the transmitting side (transmitter). In AM RLC, the reason for replying by the receiving side is to request re-transmission by the transmitting side for those PDUs not received, and this feature of re-transmission is the major characteristic of the AM RLC. Accordingly, the purpose of the AM RLC is to guarantee error-free data transmissions by performing re-transmissions, and thus the AM RLC handles the transmission of non-real-time packet data, such as TCP/IP in the PS domain. Thus, PS services can be broadly classified into those using the UM RLC for services in which delays are important and using the AM RLC for services in which error rates are important.
Considering the communication directions, TM and UM RLCs are used in uni-directional communications, while AM RLC is used in bi-directional communications because feedback from the receiving side exists. As such bi-directional communications are mainly used in point-to-point (p-t-p) communications, the AM RLC only employs a dedicated logical channel. There are also structural differences, whereby TM and UM RLCs have one structure in which a single RLC entity either only transmits or only receives, but for AM RLC, both a transmitting side (transmitter) and a receiving side (receiver) exist in a single RLC entity.
In particular, because the AM RLC must support re-transmission functions, its structure is much more complicated than that of the TM or UM RLCs. For managing re-transmissions, the AM RLC has a re-transmission buffer in addition to a transmitting/receiving buffer. Also, many other functions are performed, such as using a transmitting/receiving window for flow control, performing polling by the transmitting side to request status (state) information from the peer RLC entity of the receiving side, sending a status report by the receiving side to report its buffer state to the peer RLC entity of the transmitting side, using a status PDU for carrying status information, performing a piggyback function to insert the status PDU into the data PDU in order to increase data transmission efficiency, and the like. Also, to support these functions, the AM RLC requires various types of parameters, state variables, and timers.
As VoIP is a PS voice service, the UM RLC is used to transmit and because it is a bi-directional service, two UM RLCs are connected to a single PDCP to allow data having respectively different directions to be transmitted.
FIG. 3 depicts an RB architecture (structure) of the UMTS for VoIP data transmissions. To support VoIP, the RB shown in FIG. 3 is formed at both the terminal and the UTRAN. Because VoIP is a bidirectional service, the UTRAN provides two RTP/RTCP flows in respectively different directions. The RB for VoIP consists of one PDCP entity and two UM RLC entities, whereby each UM RLC entity operates in respectively different directions. The MAC and PHY are layers common to all RBs, thus a particular entity is not generated, and merely supports the mapping of logical channels, transport channels, and physical channels. In the PDCP, a compressor and a decompressor are formed for header compression and decompression of RTP/RTCP packets.
When providing VoIP services using the conventional RB architecture, the following problems exist. The RTP and RTCP packets are sent to the radio protocol via a single flow, but because the RTCP packets are much larger in size than RTP packets, the transmission of the RTP packets (that are sent to the radio protocol after the RTCP packets are sent) are delayed while the RTCP packets are being transmitted. Unlike RTCP packets, because RTP packets are sensitive to delays and jitter, if transmission of RTP packets is delayed for a prolonged period of time, and after the lapse of a preset time period, such RTP packets are not transmitted but discarded. Namely, when employing the conventional method for providing VoIP services, undesirable discarding of RTP packets can occur due to the transmission of RTCP packets, which is thus a cause of degradation for QoS of VoIP, and a solution to such problems is required.